home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1999 August / SGI Freeware 1999 August.iso / dist / fw_procmail.idb / usr / freeware / lib / procmail / advanced.z / advanced
Encoding:
Text File  |  1998-10-28  |  12.9 KB  |  299 lines
  1.  
  2. Discusses:
  3.         1. One home directory, several machine architectures
  4.         2. Procmail as an integrated local mail delivery agent
  5.         2a.Special directions for sites with sendmail
  6.         2b.Special directions for sites with ZMailer
  7.         2c.Special directions for sites with smail
  8.         2d.Special directions for sites with SysV /etc/mail/mailsurr
  9.         3. Changing the mail spool directory to $HOME for all users
  10.         4. Security considerations (when installing procmail suid root)
  11.  
  12.                 ---
  13.  
  14. 1. One home directory, several machine architectures
  15.    -------------------------------------------------
  16.  
  17. For users that have the very same home directory on machines with differing
  18. architectures (i.e. you need different executables), and they
  19. have to explicitly use (i.e. the system administrator did not arrange,
  20. for example, /usr/local/bin/procmail to have exactly the right contents
  21. depending on from which machine it is called) two executables of procmail,
  22. I have the following suggestion to use as a .forward file (examples are for
  23. sparc and sun3 architectures):
  24.  
  25. "|IFS=' ';if /usr/bin/sparc;then exec /home/berg/bin.sun4/procmail;else exec /home/berg/bin.sun3/procmail;fi ||exit 75 #YOUR_USERNAME"
  26.  
  27. or alternatively:
  28.  
  29. "|IFS=' ' && export IFS && exec /home/berg/bin.`/usr/bin/arch`/procmail || exit 75 #YOUR_USERNAME"
  30.  
  31. Please note, in the .forward file there can NOT be any newlines between
  32. the doublequotes, i.e. the former example *has* to be typed in as one long
  33. line.
  34.  
  35. If, on the other hand, you have to log in to every machine to read mail
  36. arrived for you on that machine, a different solution might be more
  37. appropriate.
  38.  
  39. If you have sendmail v6.xx and later, you simply create two .forward files.
  40. In the .forward file you put:
  41.  
  42. YOUR_LOGIN_NAME@your.favourite.machine
  43.  
  44. And, in a second file named .forward.your.favourite.machine you put:
  45.  
  46. "|exec /usr/local/bin/procmail #YOUR_USERNAME"
  47.  
  48. If you have an older sendmail, you could put something like the following two
  49. lines in your .forward file:
  50.  
  51. YOUR_LOGIN_NAME@your.favourite.machine
  52. "|IFS=' ';test .`/bin/uname -n` != .your.favourite.machine || exec /usr/local/bin/procmail #YOUR_USERNAME"
  53.  
  54. The leading dots are important.     Check what `/bin/uname -n` returns on
  55. your.favourite.machine, and substitute that for your.favourite.machine in the
  56. sample .forward file.  If your system does not have /bin/uname, check if there
  57. is a /bin/hostname.
  58.  
  59. With some sendmails, the last suggestion causes you to get a superfluous
  60. copy in the system mailfolder.    If that is the case, you'll have to change
  61. your .forward to something like:
  62.  
  63. "|IFS=' ';if test .`/bin/uname -n` = .your.favourite.machine ; then exec /usr/local/bin/procmail; else exec /usr/lib/sendmail -oi YOUR_LOGIN_NAME@your.favourite.machine; fi"
  64.  
  65.                 ---
  66.  
  67. 2. Procmail as an integrated local mail delivery agent
  68.    ---------------------------------------------------
  69.  
  70. Completely integrating procmail in the mail delivery means that mail is
  71. delivered as normal, unless a .procmailrc file is present in the home
  72. directory of the recipient.  This will be completely independent of the
  73. fact if a .forward file is present.  This will not break anything, it
  74. just makes the use of procmail easier because people are not required to
  75. start up procmail from within their .forward files.  Creation of a .procmailrc
  76. file will suffice.
  77.  
  78. N.B. If you *are* installing it as the local delivery agent, and users on
  79.      your system have dormant .procmailrc files without corresponding
  80.      .forward file.  Then, after the installation, these dormant .procmailrc
  81.      files will be automagically activated/used (so you might want to rename
  82.      any dormant .procmailrc files out of the way and notify the users; do be
  83.      careful, since some users might invoke procmail through other means
  84.      (cron or login) and might be surprised if it stops working).
  85.  
  86. The generic way to accomplish this (works with sendmail, smail and any other
  87. mail system that uses a local mail delivery program that takes the mail-
  88. to-be-delivered on stdin and the recipient(s) on the command line, with or
  89. without the "-d" option) is this:
  90.  
  91. Move your current local mail delivery agent (e.g. /bin/mail, /bin/lmail,
  92. /usr/lib/mail/mail.local, etc.) out of the way, and create a (symbolic or hard)
  93. link from there to procmail, as in "ln /usr/local/bin/procmail /bin/lmail".
  94.  
  95. Beware, however, that if you are using this method, /bin/mail can *only* be
  96. used to deliver mail.  On many systems /bin/mail has several uses (also to
  97. read mail or check for mail).  So, it would definitely be preferred if you
  98. could edit the invocation of /bin/mail from within your mail transport agent
  99. to invoke procmail instead (with appropriate flags, if needed).     Special
  100. directions detailing this process for some of the more popular MTAs are
  101. included in subsections below.
  102.  
  103. In addition to needing root privileges upon startup, on some systems procmail
  104. needs to be sgid to daemon or mail.  One way to check is by looking at the
  105. current mail delivery agent (usually /bin/mail) and to mimic its permissions,
  106. owner and group.  If you're not quite sure, just type "make recommend" and some
  107. suitable recommendations will be made for your particular environment.
  108.  
  109. The same might apply to the "lockfile" program, in order for it to be able to
  110. create and unlink lockfiles in the mail spool directory it might need to be
  111. sgid to daemon or mail, not to worry however, "lockfile" will not enable users
  112. to abuse the sgid/suid-ness.
  113.  
  114.                 ---
  115.  
  116. 2a.Special directions for sites with sendmail
  117.    ------------------------------------------
  118.  
  119. The following lines should take the place of the standard Mlocal definition in
  120. your sendmail.cf (as for the fields "S=10, R=20": if your system uses others
  121. or none on the current Mlocal definition, use those *instead* of "S=10, R=20"):
  122.  
  123. If you're using a sendmail 8.6.x or older:
  124.  
  125. Mlocal, P=/usr/local/bin/procmail, F=lsSDFMhPfn, S=10, R=20,
  126.     A=procmail -Y -a $h -d $u
  127.  
  128. If you're using sendmail 8.7 or newer:
  129.  
  130.     In your *.mc file, insert FEATURE(local_procmail) or edit the
  131.     sendmail.cf file and change the Mlocal definition to match:
  132.  
  133. Mlocal, P=/usr/bin/procmail, F=SAw5:|/@glDFMPhsfn, S=10/30, R=20/40,
  134.     T=DNS/RFC822/X-Unix,
  135.     A=procmail -Y -a $h -d $u
  136.  
  137. In case you were wondering why there is no 'm' flag on this definition, you
  138. can add it if you want, but I recommend omitting it (it would enhance
  139. performance very slightly, however, if one of the multiple recipients causes
  140. mail to bounce, it will bounce for all recipients (since there is only
  141. one exitcode)).
  142.  
  143. To impose a 2MB limit on mails, you could add a `Maxsize=' field like in:
  144.  
  145. Mlocal, P=/usr/local/bin/procmail, F=lsSDFMhPfn, S=10, R=20, M=2000000,
  146.     A=procmail -Y -a $h -d $u
  147.  
  148. In order to take advantage of the optional meta argument that can be passed to
  149. procmail you'd have to change the sendmail.cf file to add a $#local mailer
  150. rule to set the $@ host name (which will be substituted for $h in the mailer
  151. definition).  There is nothing forcing you to do this, but if you do, you'll
  152. gain functionality.  If you are using sendmail 8.7.* or newer, and are
  153. using the standard FEATURE(local_procmail), then the support for this
  154. meta argument is already present.
  155.  
  156. For example:
  157.     Make sure that the definition of operators in the sendmail.cf file
  158.     includes the + sign (simply tack a + to the end of the "Do" definition,
  159.     unless it already contains one).
  160.     Now look for ruleset zero (S0), skip to the end of it.    There
  161.     usually is a rule there that takes care of local delivery, something
  162.     like:
  163.         R$+            $#local $:$1        local names
  164.     Don't change that rule, leave it there.     But, right BEFORE this
  165.     rule, create a new one similar to:
  166.         R$++$*            $#local $@$2 $:$1    local argument
  167.     Depending on the actual contents of your sendmail.cf file, there
  168.     still might be some other $#local rule(s) you need to precede with
  169.     a corresponding +-handling rule, e.g. in some files you also
  170.     find:
  171.         R$+ < $+ @ $+ >        $#local $: $1
  172.     Preceed that with:
  173.         R$+ + $* < $+ @ $+ >    $#local $@ $2 $: $1
  174.     (The spaces are not significant, the tabs are!)
  175.  
  176.     Now, if someone sends mail to fred+pizza@your.domain, procmail
  177.     will be called to deliver the mail as:
  178.         procmail -a pizza -d fred
  179.     In the .procmailrc file, you can now do an assignment like:
  180.         ARGUMENT=$1
  181.     which will expand to ARGUMENT=pizza.
  182.  
  183. N.B. that if you do *not* have sendmail v6.* or older, or IDA-sendmail, and
  184. would like to make use of the meta-argument, you'll have to drop the 'l'
  185. flag on the Mlocal definition and make sure that *every* $#local invocation
  186. carries a (possibly empty) $@ host definition.
  187.  
  188. Since you are editing the sendmail.cf file now anyway, you might as well setup
  189. an extra `procmail' mailer.  This Mprocmail can then be used as a general mail
  190. filter.     For more information, see the EXAMPLES section the procmail(1) man
  191. page.
  192.  
  193. N.B. Do NOT create the extra rules mentioned in the EXAMPLES section of the
  194.      procmail(1) man page, unless you already have an application demanding
  195.      those.  Only create the completely optional Mprocmail mailer.
  196.  
  197. After having edited the sendmail.cf file you'll have to kill (terminate)
  198. the running sendmail daemon.  Then restart it.    It will *not* suffice to
  199. send sendmail a SIGHUP (unless you are running sendmail 8.7.* or newer
  200. and started it with an absolute path).
  201.  
  202.                 ---
  203.  
  204. 2b.Special directions for sites with ZMailer
  205.    -----------------------------------------
  206.  
  207. The following line should be inserted into (or take the place of any previous
  208. local definition in) your sm.conf file for the Transport Agent:
  209.  
  210. local    sSPfn    /usr/local/bin/procmail        procmail -a $h -d $u
  211.  
  212.                 ---
  213.  
  214. 2c.Special directions for sites with smail
  215.    ---------------------------------------
  216.  
  217. For smail 2.x users there are two options:
  218.  i. Move the current local-mail-delivery program (probably /bin/lmail) out of
  219.     the way, make a symbolic or hard link from procmail to the name of that
  220.     program (e.g. "ln /usr/local/bin/procmail /bin/lmail")
  221.  ii.Make sure the following macro is defined in src/defs.h:
  222.     #define LMAIL(frm,sys) "/usr/local/bin/procmail -d"
  223.  
  224. For smail 3.x users there are also two options:
  225.  i. The same solution as for smail 2.x (however, method ii is preferred)
  226.  ii.Replace any existing "local"-entry in the /usr/lib/smail/transports file
  227.     (create one, if need be) with the following two lines:
  228.  
  229. local: return_path, local, from, driver=pipe; user=root,
  230.     cmd="/usr/local/bin/procmail -d $($user$)"
  231.  
  232.                 ---
  233.  
  234. 2d.Special directions for sites with SysV /etc/mail/mailsurr
  235.    ---------------------------------------------------------
  236.  
  237. Some systems use a SysV /bin/mail that supports mailsurr.  To interface
  238. procmail with mailsurr the following two lines should be inserted in the
  239. /etc/mail/mailsurr file (preferably at the bottom):
  240.  
  241. '(.+)' '([^@!]+)' '<S=0;C=67,75;F=*;
  242.     /usr/local/bin/procmail -f \\1 -d \\2'
  243.  
  244.                 ---
  245.  
  246. 3. Changing the mail spool directory to $HOME for all users
  247.    --------------------------------------------------------
  248.  
  249. There are many different reasons why more and more sites decide not to
  250. store mail in /usr/spool/mail or /usr/mail anymore.
  251. Some of the obvious advantages when storing mail in the recipient's home
  252. directory are:
  253.     - Mail is automatically subject to the user's quota limitations.
  254.     - Often there is more room on the home partition(s) than on that
  255.       one /usr/mail partition.
  256.  
  257. The quota limitations also apply to /usr/spool/mail or /usr/mail if procmail
  258. does the delivery.  These quota limitations often do not work with the
  259. regular /bin/mail since that usually writes the mailbox with root permissions
  260. (eluding the quota restrictions).
  261.  
  262. However, if you are going to install procmail as the integrated local
  263. delivery agent, and you want mail to be delivered to, say, $HOME/.mail
  264. by default, this is what you have to do:
  265.  
  266.     Edit the procmail*/config.h file.   Uncomment and possibly change
  267.     the SYSTEM_MBOX define.     Procmail now delivers there by default.
  268.  
  269.     In order to make sure that normal mailtools can find the new
  270.     system mailboxes, you should make sure that every user has the
  271.     MAIL environment variable set to be equal to whatever you
  272.     defined SYSTEM_MBOX to be.  Some braindamaged mail programs
  273.     do not pick up the MAIL environment variable, these either
  274.     have to be patched/recompiled or you have to create symbolic
  275.     links in /usr/mail to every person's new mailbox.
  276.  
  277.                 ---
  278.  
  279. 4. Security considerations (when installing procmail suid root)
  280.    -------------------------------------------------------------
  281.  
  282. If in EXPLICIT DELIVERY mode (typically when called from within sendmail)
  283. procmail will ALWAYS change UID and gid to the RECIPIENT's defaults as soon as
  284. it starts reading the recipient's $HOME/.procmailrc file.
  285.  
  286. If NOT in explicit delivery mode (typically when called from within the
  287. recipient's $HOME/.forward file) procmail will ALWAYS change UID and gid to
  288. the real uid and gid of the INVOKER (effectively losing any suid or sgid
  289. privileges).
  290.  
  291. These two precautions should effectively eliminate any security holes because
  292. procmail will always have the uid of the person whose commands it is executing.
  293.  
  294. To summarise, procmail will only behave better if made suid/sgid something, in
  295. fact, making procmail suid/sgid something will *improve* security on systems
  296. which have dynamically linked libraries.
  297.  
  298.                 ---
  299.